1. Field of the Invention
The invention described herein is most directly related to graphical user interfaces supporting a user's interaction with a computer system. More specifically, the invention allows configuring a Graphical User Interface (GUI) into multiple component distributions and then selecting an appropriate configuration in accordance with associated conditions or desired operations.
2. Description of the Prior Art
As modern computer applications incorporate more features into their interfaces, apportioning the workspace to accommodate the myriad of controls and data displays presents challenges to both the interface designer and the ultimate user of the application. Even previously uncomplicated office programs have evolved over the years into more capable and more complex products, necessitating the authors of such tools to find techniques to somehow present their otherwise overly complex interfaces in some manageable form. No longer are entries created in the main menus for every single command that the program supports, as to do so would overcrowd the interface to render such controls much less effective than any of their predecessors.
Referring to FIG. 1A, there is shown a window configuration of an office application embodying several features typical of the current art. The illustrated application is taken from MICROSOFT POWERPOINT, which produces slides for a user-created presentation, typically in a business setting. To that end, the user interface includes a primary data view pane 110, alternatively referred to herein as a “canvas”, a menu banner 120, from which drop-down menus are accessed, and a plurality of user-operable tools located on toolbars 130a-130b. The user interface also provides navigational and application assistance in the form of an outline/slide view pane 140 and a task assistant pane 150.
Modern user interfaces, such as that illustrated in FIG. 1A, contain many user interface components or controls including, but not limited to, banner menus, toolbars, and docking windows. There may be multiple and many toolbars, each of which containing controls suitable to a particular sub-task of the user's design process. The MICROSOFT WORD program from the MICROSOFT OFFICE 2003 SUITE alone contains 22 toolbars. During particular design tasks, such as authoring a document, a user may choose to use and display any or all of these toolbars, but is more likely to make visible only a smaller subset.
A dynamic task pane is one technique used for simplifying the interface of such feature-rich programs. As a specific example, a control to facilitate the animation of a presentation created by POWERPOINT is not provided through any of its standard banner menu choices. Instead, the user operates a control 160 on the task pane, invokes thereby an animation task. The task pane, a separate though related window, is subsequently transformed to an animation task configuration 152 so as to provide access to the necessary animation menus, buttons and other GUI controls, as shown in FIG. 1B. As the user further switches to other tasks via the pull-down choice control 160 at the top of the task pane, the task pane 150 itself changes dynamically to provide access to the appropriate controls for those tasks.
FIG. 1C depicts another exemplary configuration 154, which presents controls related to the task of choosing a layout for a newly created slide in the presentation. Due to the ready availability of the controls on such panes, they are often referred to as “assistant” panes or windows, or sometimes just “assistants”.
By comparison to such office applications, the user interfaces of modern Electronic Design Automation (EDA) tools are extremely complex, reflecting the extreme complexity typical of modern Integrated Circuit (IC) design processes. As the complexity of IC manufacturing has increased over time, so too has the complexity of the circuit design process. Accordingly, tool sets for carrying out IC design processes have grown tremendously. The manageability of known EDA user interfaces has progressively degraded from that of earlier, simpler versions, due largely to the sheer number of controls needed to engineer a complete circuit design.
Many office and Integrated Development Environment (IDE) applications of the prior art tend to operate on textual data, which most often permits the same user interface components to be used for different text types. Most modern EDA and other such applications, however, operate on richer sets of data having fundamentally different interactive requirements. Certain user interface components or windows are usable on only a few data views or types, while many others are usable more or less on but a single particular view type.
For example, it may be appropriate for a property editor control to be presented when editing symbol schematics. On the other hand, a constraint browser, which is presented for annotating constraints onto a schematic, is likely quite inappropriate for simple schematic symbol editing tasks. The presence of such a browser when editing symbol views would unduly clutter the user's screen, and likely cause user confusion and frustration.
Modern GUIs now simply offer too many choices in terms of menu picks, buttons, sliders, tables, and other “widgets”, the vast conglomeration of which may very easily overwhelm the user. Even more so than in office applications, the user interface controls necessary for completing a given IC design task in an EDA application may be distributed over numerous higher-order controls of different types, such as docking windows, menus, toolbars, and the like. In order to be truly useful in such applications, a user interface must be reduced in complexity despite the elaborate nature of the user's work task. Such reduction would entail simultaneous control of such things as visibility, positioning, float/dock state, and geometry/size of multiple interface components under much greater degrees of freedom than in a simple office application. Moreover, such user interface should support multiple such configurations, to accommodate the numerous and varied complex tasks required of the modern circuit designer.
In many applications, users may require different combinations of interfaces in different user-specific tasks unknown to the original software author or vendor. Present interfaces do not afford the formation of new interface configurations, much less the storage of such in a manner that facilitates recall, such as through some form of naming scheme.
In IC design, the situation is often encountered where a designer, when entering constraints, for instance, may need to closely examine a large portion of his schematic or layout at an appropriate zoom level. All available screen pixels must be freed up for a sufficiently large portion to be displayed, but not to the point where navigational context is lost. The capability to temporarily dismiss then restore all or part of the toolbars and docking windows with ease would enable the designer to meaningfully inspect his design, and then just as easily un-dismiss or re-invoke the toolbars and docking windows to resume modifying design object properties, adding constraints, etc. Clearly, data processed by typical text-based office or IDE applications have no such inspection requirement and such applications thus do not offer this capability. Whereas, GUIs of some modern applications provide zoom and full-screen switching to change the viewing scale and size of a data view, maintaining the zoom level in a particular context during removal then subsequent replacement of GUI tools for a particular abstraction of the data being zoomed is heretofore unseen in known systems.
Thus, the need exists for a user interface configuration system that scales the vast complexity of modern EDA tool sets to a given task and to multiple levels of abstraction in the data being viewed and edited.